Міністерство освіти і науки України
Національний університет „Львівська політехніка”
Кафедра ЕОМ
Звіт
з лабораторної роботи №2
з дисципліни
“ Тестування програмних засобів ”
Львів 2012
Мета: розглянути фреймворки для автоматизованого тестування програмного забезпечення.
Виконання роботи:
Фреймворк SoapUI
Soap UI - веб-сервіс з відкритим кодом, призначений для тестування додатків з сервіс-орієнтованою архітектурою (SOA). Його функціональність включає перевірку, розробку, симуляцію, виклик і фальшивий викли веб-сервісу, функціональні, завантажувальні і піддатливе тестування веб-сервісу. Комерційна версія soapUI Pro, взагальному фокусується на досягненні продуктивності і розроблена сторонніми компаніями.
Рис. 1 Головне вікно Soap UI
Перший реліз Soap UI був завантажений на Sourceforge в листопаді 2005. Це ПЗ з відкритим кодом випущене з ліцензією GNU/GPL. Цей фреймворк було завантажено більш ніж 2000000 разів з часу першого релізу. Він побудований на платформі Java і використовує Swing для інтерфейсу користувача, тому він є кросплатформенним. Сьогодні він підтримує IDEA, Eclipse i NetBeans.
Він підтримує такі можливості:
Перевірка веб-сервісів
Запуск веб-сервівсів
Розробку веб-сервівсів
Емуляцію роботи веб-сервівсів і
Функціонал завантаження і тестування безпеки веб-сервісу
Одна з основних проблем, які виникають під час інтеграції різних систем між собою це те, що на момент розробки ці сервіси або не існують, або не завжди доступні (або доступні з великими проблемами). Таке може статися, якщо, наприклад, компанія розробляє додаток на базі SOA, і кожен з сервісів створюється паралельно різними людьми. Чекати поки одна людина закінчить свій компонент, перш ніж приступати до своєї розробці - не найефективніший спосіб. Добре, якщо всі сервіси знаходяться в руках однієї компанії, тоді можна ще хоч якось домовитися, але в реальності все буває якраз навпаки - сервіси знаходяться під контролем сторонніх компаній і буває дуже складно вплинути на їх розробку. Щоб це було легше зрозуміти - уявімо гіпотетичну ситуацію.
Існує якась компанія, яка займається виконання різного роду технічних робіт, наприклад ремонтує / контролює / встановлює охоронні системи. У компанії є регістр даних клієнтів, що зберігається в якійсь базі даних. Доступ до цієї бази даних можна отримати через спеціальний інтерфейс, через який дані про клієнтів заносяться в систему, проглядаються і оновлюються. Коли приходить новий замовлення, то він оформляється у ще одній спеціальній системі замовлень, після чого на об'єкт відправляється технік, який власне і займається обслуговуванням охоронних систем. У техніка є загальна інструкція, що описує, як він має діяти на об'єкт, але, в принципі, кожен з них діє за власним розсудом, виходячи з ситуації на місці. Після виконання роботи - технік створює звіт у вільній формі, який зберігається в певної третьої системі.
Припустимо, що компанія хоче покращити якість звітів. Вона хоче бачити, які саме роботи були зроблені, скільки часу займала кожна з них, які проблеми найбільш часті і так далі. Всю цю інформацію планується використовувати для поліпшення продуктивності і, як результат, зниження витрат і збільшення обороту. Для цього планується впровадити нову інформаційну систему, яка дозволить стандартизувати робочий процес. Виглядає це як список завдань / checklist на PDA техніка, які він повинен виконати, відвідавши об'єкт. Ця ж система дозволить пакувати замовлення таким чином, щоб одному техніку діставалися замовлення в одній і тій же частині міста, тим самим збільшивши кількість об'єктів, які він може відвідати за день. Наймати працівника в штат компанія не бажає і тому наймається контрактор, який, власне, і інтегрує ці системи між собою. Ось тут починається саме інтересaное.
Як правило, бази даних, що зберігають клієнтів, замовлення, звіти, доступні усередині корпоративної мережі, але не видно зовні з причин безпеки. У той же час, навіть перебуваючи всередині мережі, доступ можна отримати тільки прямо приєднати до ...